fix: avoid char-boundary panic in NBReader::try_read#172
Conversation
SAY-5
force-pushed
the
fix-try-read-char-boundary
branch
from
298398d to
534e491
Compare
|
Split into a test commit that shows the panic on multi-byte input followed by the fix, per the contrib guide. |
SAY-5
force-pushed
the
fix-try-read-char-boundary
branch
from
534e491 to
f9e11ce
Compare
|
Restructured per the c-test guide: the test commit now documents the panic with should_panic, and the fix commit drops should_panic and asserts the decoded chars. Pushed. |
| // pump bytes from the reader thread into the buffer | ||
| for _ in 0..10 { | ||
| let _ = r.try_read(); | ||
| thread::sleep(time::Duration::from_millis(5)); |
There was a problem hiding this comment.
From #172 (comment)
NBReader::read_into_buffer reads from a background thread that pipes the cursor bytes into self.buffer over an mpsc channel, so a single call right after construction usually finds the buffer still empty. The 5ms sleeps give that thread time to deliver bytes between try_read calls. Happy to switch to a synchronous fixture or a poll loop if you'd prefer not to depend on a timed delay.
There was a problem hiding this comment.
Would prefer to avoid the sleeps. We slow down test runs and risk race conditions.
This comment was marked as duplicate.
This comment was marked as duplicate.
2 participants
The internal buffer stores raw input bytes as latin-1 chars, so a byte >= 0x80 becomes a two-byte char and
drain(..1)could land off a char boundary and panic. Drain the first char by its UTF-8 length instead.Closes #32